Bump to log4j-slf4j2-impl v2.25.0 #1269
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Throughout this entire time, for anybody cloning the repository, setting
up the `config.json.template`, following all the steps from the GitHub
wiki we have verbatim and running the bot, leads to a SLF4J(E)
stacktrace into the console almost as soon as the program begins
execution, regardless of the environment:
SLF4J(E): Unexpected problem occurred during version sanity check
SLF4J(E): Reported exception:
java.lang.AbstractMethodError: Receiver class org.apache.logging.slf4j.SLF4JServiceProvider does not define or inherit an implementation of the resolved method 'abstract java.lang.String getRequestedApiVersion()' of interface org.slf4j.spi.SLF4JServiceProvider.
at org.slf4j.LoggerFactory.versionSanityCheck(LoggerFactory.java:385)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:189)
at org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:511)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:497)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:446)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:472)
at org.togetherjava.tjbot.Application.<clinit>(Application.java:35)
There has been no major hurdle noted after this exception being thrown,
at least not one that I am personally aware of.
Fix this by updating `log4j-slf4j2-impl` to the latest stable version as
of writing this (2.25.0). As a result, the stacktrace is entirely gone
and logging appears to be behaving normally.
By doing this we also prevent discouraging novice contributors from
contributing by falsely getting them to believe that they have performed
something wrong during setup.
Signed-off-by: Chris Sdogkos <work@chris-sdogkos.com>
|
hm why doesn't dependabot trigger this version bump in the first place? |
|
Good question. I wondered the same thing. I suspect it comes from a misconfiguration in |
Zabuzard
added
enhancement
Zabuzard
approved these changes
Jun 30, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Throughout this entire time, for anybody cloning the repository, setting up the
config.json.template, following all the steps from the GitHub wiki we have verbatim and running the bot, leads to a SLF4J(E) stacktrace into the console almost as soon as the program begins execution, regardless of the environment:There has been no major hurdle noted after this exception being thrown, at least not one that I am personally aware of.
Fix this by updating
log4j-slf4j2-implto the latest stable version as of writing this (2.25.0). As a result, the stacktrace is entirely gone and logging appears to be behaving normally.By doing this we also prevent discouraging novice contributors from contributing by falsely getting them to believe that they have performed something wrong during setup.